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SPECIFICATION 
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TO ALL WHOM IT MAY CONCERN: 

BE IT KNOWN that we, Jonathan Cherneff and Krishna Kumar, residing in 
the State of Maryland, and John Fors, residing in the state of California, have 
invented new and useful improvements in a 

SYSTEM FOR SCHEDULING PRODUCT PLANNING 

of which the following is a specification: 



Patent Application /0544MH-36339 



Page 1 of 1 



CROSS REFERENCE TO RELATED APPLICATIONS 

1 The present application claims the benefit of US Provisional Application 

2 60/158,650, filed 8 October 1999, titled SYSTEM FOR CONSTRAINT-BASED 

3 PROJECT SCHEDULING AND RESOURCE OPTIMIZATION, which is hereby 

4 incorporated by reference. It also contains material in common with co-pending 

5 US utility applications No. , attorney Docket No. 0544MH- 

6 36340, titled SYSTEM FOR PLANNING A NEW PRODUCT PORTFOLIO, and 

7 No. , attorney docket No. 0544MH-36338, titled SYSTEM 

8 FOR PLANNING A NEW PRODUCT RELEASE, both filed concurrently herewith, 

9 and both hereby incorporated by reference. 

BACKGROUND OF THE INVENTION 

10 1 . Field of the Invention: 

11 The present invention relates generally to scheduling systems, and more 

12 particularly to a system and method for scheduling development of a portfolio of 

13 new products to be developed in accordance with a development plan. 

14 2. Description of the Prior Art: 

15 In today's marketplace, development of new products to be brought to 

16 market is becoming of increasing importance. In many industries, product life 

17 cycles are becoming shorter, increasing the importance of new product planning 

18 and introduction. Planning of new products is usually based upon a decision by 
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1 management as to what new products will sell the best, and hopefully provide the 

2 best profit margins for the company. 

3 Once a portfolio of products to be developed has been selected, it is 

4 necessary to implement scheduling controls to implement the plan. Feedback 

5 regarding the actual status of the various development projects is necessary to 

6 ensure that product development proceeds on schedule, or that trouble areas 

7 can be addressed. 

8 With present systems, it is difficult to trace progress of the plan. Further, 

9 when problems occur with suppliers of needed materials, the adverse impact on 

10 the project schedule is usually found out just before the materials are needed. 

11 Competition between projects within a company can upset development 

12 schedules, because of lack of availability of needed resources. 

13 It would be desirable to provide a product development scheduling system 

14 which allowed a company to better schedule its resources for product 

15 development projects. 
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SUMMARY OF THE INVENTION 

1 In accordance with the present invention, a product development scheduler 

2 uses a distributed, constraint based system for modeling allocation of resources. 

3 All resources for all active development projects are provided at a central location, 

4 so that resources are not allocated twice across different projects. Real time 

5 availability of resources allows accurate modeling, and changes in resource status 

6 are reflected by the scheduler. Availability of materials is tracked through the 

7 supply chain to ensure true availability for planning purposes. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

1 The novel features believed characteristic of the invention are set forth in the 

2 appended claims. The invention itself however, as well as a preferred mode of use, 

3 further objects and advantages thereof, will best be understood by reference to the 

4 following detailed description of an illustrative embodiment when read in 

5 conjunction with the accompanying drawings, wherein: 



6 Figure 1 is a diagram outlining a preferred new product planning process; 

7 Figure 2 is a high level block diagram illustrating a preferred approach to 

8 new product planning; 

9 Figure 3 is a diagram illustrating the use of alternative projects for 

10 developing a product; 

1 1 Figure 4 is a diagram illustrating a plurality of tasks contained in a project 

12 Figure 5 is a diagram illustrating a project having tasks organized in phases 

13 Figure 6 is a sample set of financial projections over time; 

14 Figure 7 is a data flow diagram illustrating utilization of the preferred 

15 planning system; 

16 Figure 8 is a data flow diagram illustrating use of a preferred development 

17 scheduler; 
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Figure 9 is a diagram illustrating operation of a scheduling system by various 

users; 

Figure 10 is a block diagram illustrating subtasks; and 

Figure 1 1 is a diagram illustrating the uses of different layers of resources. 
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DESCRIPTION OF THE PREFERRED EMBODIMENT 

1 The system and method described below is useful for scheduling 

2 development planning projects, and for monitoring progress of those projects after 

3 they are initiated. The project scheduler is part of an overall system that begins 

4 with initial selection of products to be developed. The selection process generates 

5 an initial plan for its projects, which is then used during the development process. 

6 At the planning level, resources are allocated as an amount during a time period, 

7 which can be selected as one month, for example. During the execution phase, 

8 resources are allocated by program managers at a finer granularity, for example on 

9 a daily basis. Also, in the planning stage, individuals who will be performing 

10 particular parts of the work are not identified, but they are at the execution stage. 

11 The following discussion begins with a description of the planning process 

12 used to generate a schedule to be used for product development. This is followed 

13 by a description of the details that specifically apply primarily to the execution of a 

14 development schedule in accordance with the preferred embodiment. 

15 Figure 1 illustrates the planning process generally at a high corporate level. 

16 The portfolio planner system resides on a server 10 which is accessed directly or 

17 indirectly by the various people involved in the planning process. Those people 

18 include program managers and resource managers 12 who preferably access the 

19 server 10 through one or more web servers 14. program managers and resource 

20 managers 12 access a login web page 16 that gives them access to the underlying 
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1 web pages 18 used to manipulate data and generally access an underlying 

2 database 20. 

3 Portfolio analysts 22 access the portfolio planner server 10 through various 

4 scenario building tools 24 not available to program and resource managers 12. A 

5 portfolio team 26 makes final decisions as to which products are to be developed, 

6 and determines the various high level strategies to be implemented. They are 

7 assisted in their decision making by the analysts 22. It will be appreciated by those 

8 skilled in the art that this division of work is only a preferred suggestion, and other 

9 high level relationships will work with the system described below. 

10 Figure 2 indicates the type of information used by the system to develop an 

11 optimum portfolio. Planning engine 28 accepts inputs and generates development 

12 plans as described below. Users 30 both provide initial inputs to planning engine 

13 28, and assess results that are generated. Planning engine 28 uses various types 

14 of data as inputs, and modifies data as the planning process proceeds. Data 

15 regarding projects 32 is used to define what steps are necessary to develop each 

16 new product under consideration. Data regarding the resources 34 available to 

17 develop new products is required, as is information regarding the financial models 

18 36 that project the impact on profits of developing each product by a set of 

19 introduction dates. 

20 A feature that adds to the usefulness of this system is that forward looking 

21 financial models are incorporated into the development planning strategy. Because 

22 late product introduction can have such a devastating impact on the profit 
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1 contribution made by a product over its lifetime, it is necessary to consider timing 

2 effects in order to develop a useful product development plan. As is discussed in 

3 more detail in connection with Figure 6, the present system provides that different 

4 profit projections be provided for various new product introduction dates. 

5 Some portions of the preferred system are similar in nature to planning 

6 systems known in the art. Various portions of the preferred system are described in 

7 connection with Figures 3 through 5. 

8 Referring to Figure 3, each product under consideration for development 

9 may be developed by one or more alternate projects. In this example, Project A 

10 can be developed by a project X 40, which is currently selected as the active 

1 1 project for this project. Only one development project is planned for any single 

12 project, to prevent different development projects for a product from being pursued 

13 simultaneously. Portfolio planners can select alternate projects, such as project Y 

14 42 or Project Z 44, to assess the impact on overall profitability and scheduling of 

15 these alternate projects, but only one project at a time is selected. 

16 Referring to Figure 4, any given project 46 is comprised of a sequence of 

17 tasks. A simplified sequence of tasks 48 - 58 is shown in Figure 4, and assumes 

18 that two components are needed to be developed to come up with a new product. 

19 In many cases, many of the components in a new product can be reused from 

20 earlier products, and integrating them is the primary concern. 
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1 Tasks have constraints that are used to sequence them for planning 

2 purposes. Some tasks must be completed before others, and a set of constraint 

3 rules is provided to enforce the proper ordering. Other tasks can be complete in 

4 parallel, with component development not depending on the development of some 

5 of the other product components. These relationships are expressed as a set of 

6 constraint rules for each project. The Planning engine enforces these constraints 

7 when scheduling development of products. The constraints are especially 

8 important when multiple products are being scheduled for concurrent development, 

9 which is the most common scenario in which the present system is useful. 

10 Projects may be broken down into phases, which are simply collections of 

11 related tasks as defined by those using the system. Referring to Figure 5, a 

12 product A 60 is to be developed through project X 62, which in turn consists of 

13 tasks 64 - 72. These tasks are shown as broken into 3 phases 74, 76, 78, which 

14 occur in sequential order. In a planning situation where it is presumed in advance 

15 that not all development projects will proceed to completion, the use of project 

16 phases can enhance the accuracy of the portfolio projections. 

17 Each task requires certain resources. These can be defined as, for 

18 example, a certain number of person days to be made available during a specified 

19 timeframe by a specified resource. Each resource has a capacity, defined as the 

20 number of person days which are available. This capacity can change over time, 

21 and in particular can change depending upon the day of the week, the amount of 

22 overtime that can be worked, the impact of holidays, etc. The process of 
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1 scheduling projects involves scheduling tasks, which uses up available resources. 

2 As schedules are developed, the available resources diminish. 

3 When there is a possibility that a project will not be completed, a probability 

4 of completion can be assigned in advance to each phase of the project. For 

5 example, it can be assumed that the initial phase 74 of the project is 100% likely to 

6 be performed. Whether product development continues will depend on the results 

7 of the first phase, and a probability of 80% can be assigned, for example, to second 

8 phase 76. In this example, assume that the probability of executing the third phase 

9 78 is 50%, once the second phase is completed. 

10 The resources that will be used by project 62 are multiplied by the 

11 appropriate probabilities when resource allocation is performed at the planning 

12 stage. Thus, the resources that would be needed by the second phase 76 are 

13 multiplied by 0.8 to take into account the lesser probability that they will be needed 

14 at all. For the third phase 78, the required resources are multiplied by 0.8 * 0.5 = 

15 0.4, because the third phase depends on both a decision to be made after second 

16 phase 76 completion (50%) and the probability that the second phase will be 

17 performed (80%). The resources normally required for each phase are multiplied 

18 by the product of all preceding phase probabilities to reach a resource allocation 

19 multiplier for that phase for planning purposes. 

20 An important part of the preferred system is the inclusion of financial 

21 modeling in the product development planning process. As described above, 

22 expected profits over the lifetime of a product are a function of the introduction date 
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1 of the product, as well as numerous other factors. In general, creating a model 

2 projecting the financial return to be expected for a product is known in the art. The 

3 preferred system requires that a series of financial projections be run in order to 

4 assist the planning process. 

5 Figure 6 illustrates a simple example of the time element as it relates to the 

6 profit projections used in the preferred embodiment. A graph 74 includes three 

7 profit curves 76, 78, 80 which are shifted in time to represent different product 

8 introduction dates. IN this example, the peaks of the curves diminish as the 

9 product is introduced later. At some point, there may be only minimal profits if the 

10 product is introduced too late. The total profits over the lifetime of a product is 

1 1 found by integrating under the separate profit curves. 

12 Each possible product introduction date will have a corresponding overall 

13 profit figure associated with it. Some products may be relatively insensitive to the 

14 date of introduction; these products can be developed to be introduced an any 

15 convenient time. Other products are extremely time sensitive, and must be 

16 developed as quickly as possible. The time impact on product contribution to 

17 corporate profits is used as part of the data considered in the optimization process. 

18 The portfolio planning process is a process of optimizing a set of inputs to 

19 maximize an output value. In the preferred system, the output to be maximized is 

20 the overall profit to be made by products to be developed. This is shown in Figure 

21 7, in which a planning engine 90 generates an output financial projection 92 

22 consisting of the expected profit to be generated by a given product mix 94. 
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1 Product mix 94 is provided as an input to planning engine 90, and defines the 

2 products that are in the portfolio and available for consideration. Data defining 

3 available resources 96, project definitions 98, and time dependent financial 

4 projections 1 00 are also provided. 

5 As described above, resources 96 is a list of all available resources needed 

6 to develop new products. Not all resources available to the company need be 

7 considered; only those that relate to new product development are of interest. 

8 Project definitions 98 are the list of tasks required to develop each possible product, 

9 as described above. The financial projections 100 are also as described above. 

10 Project definitions 98 and financial projections 1 00 are provided separately for each 

11 possible product to be developed. Resources 96 includes all resources that are 

12 available. 

13 The planning process begins when a possible portfolio of new products is 

14 provided as the product mix 94. Planning engine 90 generates a schedule 104 for 

15 product development in the traditional manner, utilizing the sequence and timing 

16 constraints contained in the project definitions. Development projects are 

17 scheduled utilizing available resources, and the completion dates for the various 

18 projects under consideration generates a dollar number for each product based 

19 upon introduction date. Part of the scheduling process is the selection of which 

20 products are to be developed; this list is preferably chosen to maximize overall 

21 projected profit. A user determines whether the financial result and plan is suitable, 

22 and may change the product mix if necessary. The planning process is an open 



Patent Application /0544MH-36339 



Page 13 of 13 



1 loop process, with the user changing the portfolio in order to determine the impact 

2 on overall profitability. 

3 As is normally the case, the scheduling process balances weighted interests 

4 to generate a best overall schedule according to its inputs. The present system 

5 uses financial projections, which differ depending on introduction date, as a 

6 weighted factor in the optimization process. Thus, products which lose significant 

7 profitability if they are introduced late are more likely to be scheduled for fastest 

8 introduction, while less time sensitive products may be scheduled later. Of course, 

9 those products that contribute the most to profitability have a priority in the 

10 scheduling process. 

11 In addition to the projected profit number 92, the present system also 

12 generates a schedule to control the development process. This schedule is used 

13 by project managers to determine their deadlines so that overall corporate 

14 schedules and profit targets can be met. 

15 The schedule 104 generated by planning engine 90 is at a higher level than 

16 needed to implement the plan. Schedule 104 allocates resources by function, but 

17 does not performed a detailed allocation. The detailed allocations are taken care of 

18 by a separate scheduler that accounts for resources at a more detailed level, and 

19 accepts feedback regarding the progress of the various development projects 

20 selected with the planning engine 90. 
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1 During the planning stage, resources are preferably dealt with a higher level 

2 than is needed for detailed scheduling. The same is true for scheduling of tasks; 

3 larger tasks often need to be broken down into subtasks at the scheduling level in 

4 order to effectively schedule resources and monitor progress. At the same time, 

5 financial considerations are not part of the detailed scheduling process, and so are 

6 not included once the portfolio mix has been determined. 

7 Figure 8 shows the data flow for the development scheduler that 

8 corresponds to Figure 7 for the portfolio planner. Referring to Figure 8, schedule 

9 104 is used as the initial input to scheduler 106. Resources 108, project definitions 

10 110, and supply chain information 112 are also used as inputs to scheduler 106. 

11 As described below, resources 108 and project definitions 110 are similar to, but 

12 more detailed than, resources 96 and project definitions 98 used with the planning 

13 engine 90. 

14 Scheduler 106 tracks actual progress of all projects 114 for the company, 

15 based upon input by users 116 who track tasks as they are completed. Scheduler 

16 1 06 generates a detailed schedule 1 1 8 that can be used by people in the company 

17 to plan their development schedules. 

18 While the portfolio planner is used primarily by strategic management, the 

19 development scheduler is used primarily by project managers and resource 

20 managers. The preferred relationship between the various users and the scheduler 

21 is illustrated in Figure 9. The scheduling system is implemented on server, where it 

22 can be accessed by all users that need access. In this diagram, master planners 

Patent Application /0544MH-36339 Page 1 5 of 1 5 



1 122 are the strategic managers responsible for selecting the product mix as 

2 described above. Their responsibility does not completely cease once the portfolio 

3 has been defined, however, because schedules may need to change as a result of 

4 unplanned or unforeseen circumstances. Generally, the master planners 122 are 

5 not involved in the day to day operation of the scheduler 120, but only become 

6 involved if a change is needed to the schedule. 

7 Project managers 124 are a primary user of the scheduler. They maintain 

8 detailed information about their projects, and define low level changes that need to 

9 occur. If the master schedule calls for a project to complete two tasks during a 

10 particular month, it is the project manager's task to ensure that the tasks are 

11 actually completed. A detailed schedule is generated by the scheduler, and 

12 followed by the project team to the extent possible. The original schedule 104 

13 generated by the planning engine 104 is broken down into the required level of 

14 detail by the scheduler. 

15 Project team members use the scheduler to view their schedule, and enter 

16 data showing the actual progress made. As tasks are completed, this data is 

17 entered into the scheduler so that progress can be confirmed as meeting the 

18 schedule. Details of the schedule may have to be changed depending on the 

19 progress actually made. Unless these changes will impact any deadlines set in the 

20 master schedule, no approval is required from master planners 122. 

21 Resource managers 128 use the scheduler 120to monitor and update the 

22 status of the resources for which they are responsible. If the capacity of a resource 
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1 changes, this information is entered into the scheduler. Loss of capacity may 

2 impact the ability to meet scheduled deadlines, which raises a flag to project 

3 managers 124 and may require intervention by master planners 122. Resource 

4 planners are also responsible for ensuring that required materials are available. 

5 Because some of the required materials are obtained from outside suppliers, 

6 resource planners 128 use supply chain tools, such as those available from i2 

7 Technologies, to track suppliers and ensure that all required materials are ready in 

8 time. If required materials will not be ready, the effect on the schedule is the same 

9 as if a required resource would not be available. This may again necessitate a 

10 change to the schedule by master planners 1 22. 

11 Application administrators monitor functioning of the system, and assist 

12 others in using it. They generally have no input regarding schedules. 

13 During the portfolio planning stage, tasks are defined at a relatively high 

14 level. A task could be, for example, to test a product or a component of a product. 

15 This test might take a relatively long period of time, perhaps several weeks, and 

16 use several different resources. For detailed scheduling purposes, it is preferable 

17 to break tasks down into smaller pieces in order for them to be more effectively 

18 scheduled. 

19 Figure 10 shows a task broken down into subtasks. Task 140 is a test set, 

20 and comes sequentially before task 142 as described above. This is a sufficient 

21 level of detail for planning purposes, but is presumed for this example to be 

22 insufficient in detail for scheduling purposes. Task 140 has three subtasks 144, 
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1 146, 148 that are performed in sequential order. As described above, subtasks 

2 may be concurrent if that is appropriate. Sequential tasks are defined by 

3 constraints associated with the task, that requires certain tasks to be completed 

4 before others begin. 

5 Subtasks may in turn be broken into smaller subtasks, as is shown. Subtask 

6 144 has two further subtasks 150, 152, which may be performed either sequentially 

7 or concurrently. The levels of subtasks can extend down as far as necessary to 

8 properly define a higher level task. 

9 Each leaf subtask on the task hierarchy tree, subtasks 150, 152, 146, and 

10 148 in Figure 10, has associated with it one or more resources. The resources 

11 needed for task 140 is the sum of all resources needed for its subtasks. Because 

12 standard tasks may comprise a fairly complex set of subtasks, they may be pre- 

13 stored as templates to be used whenever the task is required. This simplifies the 

14 planning and scheduling process, because the details of each task are generated 

15 carefully once, and reused many times. The high level time and resources required 

16 for a task are used by the portfolio planner; the details contained in the subtasks 

17 are used by the detailed scheduler. 

18 In a similar manner, resources are preferably defined in a hierarchy, as 

19 illustrated in Figure 11. In this example, resource A 160 is comprised of three 

20 separate sub-resources 162, 164, and 166. Resources 162 are further broken into 

21 a lower level of resources, with resources 168 and 170 making resource 162. the 

22 details of resource 1 64 are omitted for simplicity in explanation. 
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1 The resource hierarchies are defined to match resources as they are 

2 actually applied within the company. At the lowest sub-level, a resource could 

3 comprise a single person, or a group that works as a unit. For example, resource 

4 160 could be defined as the testing department, with resource 162 being the user 

5 interface group, and resources 1 68 and 170 being testing teams or individuals. The 

6 lowest levels of subtasks 150, 152 will generally require resources at the lowest, 

7 detailed levels. 

8 At the portfolio planning level, resource 160 is used in the aggregate by 

9 defining a number of testing days available during a month and being allocated on 

10 that basis. During detailed scheduling, the testing teams to be used must be 

11 identified when the project is scheduled. The hierarchical definition of tasks and 

12 resources described herein allows for higher level plans to be easily allocated to 

13 lower level tasks and resources. Depending on the nature of specific tasks and 

14 resources, lower levels may have to be used even during portfolio planning. 

15 However, in many instances this will not be necessary, and the details can be 

16 hidden by layers of hierarchical levels. 

17 The scheduler preferably operates as follows. High level schedule 104 is 

18 provided, and scheduled in the normal manner for a relatively short future time 

19 period. For example, if the planning schedule is determined in months, and the 

20 detailed schedule operates in units of days, a detailed scheduling window might 

21 extend only 3 months into the future. After that time, high level tasks are scheduled 
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1 using high level resources in accordance with the master plan. Lower levels of 

2 tasks and resources are only scheduled during the detailed scheduling window. 

3 Figure 12 shows the information used to define each resource 180. Each 

4 resource 180 has a capacity 182, defined as the number of hours that the resource 

5 can work in a day. These may be broken down into normal and overtime hours if 

6 the resource is capable of overtime hours. 

7 Each resource 1 80 also has an availability 1 84, which is basically a calendar 

8 of when the resource is available. Assuming the resource to be a single person, for 

9 example, vacation schedules, holidays, and other calendar information must be 

10 provided. Availability as calendared here modifies the capacity values described 

1 1 with relation to box 1 82. 

12 Each resource also has an ability 1 86, which is a general term for the type of 

13 work that can be performed by the resource. Ability is further broken down into 

14 attributes 190, which describes the types of work that can be performed by the 

15 resource, and competency 188, which describes how well the resource can do the 

16 job. A resource 180 can have several different attributes, if desired and 

17 appropriate, and corresponding competencies for each attribute. These abilities 

18 are used to match tasks with appropriate resources. 

19 Tasks also have a definition, as shown in Figure 13. Task 200 is assigned a 

20 type, which is generally defined to be a work task. Work tasks have one or more 

21 resource requirements. A task may also be given a type of milestone, which is 
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1 simply a placeholder used for management purposes to indicate that a project 

2 milestone has been reached. Milestone tasks have neither resource requirements 

3 nor a duration. 

4 Hierarchy relationship 204 is where the pointers to related tasks are stored. 

5 The hierarchy relationships among tasks are what defines the task hierarchies 

6 described previously. Precedence relationships between, the sequencing between 

7 them, are also defined here. Duration 206 is simply a time that the task will take to 

8 complete. When a task is scheduled, the user specifies the resources needed and 

9 the duration. Preferably, an additional time buffer can be specified, which is an 

10 additional allowed amount of duration in which the task can be completed. 

11 Resources 208 are assigned to tasks. A task may require more than one 

12 resource, but a single resource is usually needed for a single task. Resource 

13 requirements are associated only with tasks that do not have subtasks; the 

14 resources for a task having subtasks are defined to be those of its children. 

15 Several different aspects of resources must be defined. These are choice 

16 210, amount of work 212, and ability 214. Choice 210 actually specifies the 

17 resource to be used. This may be a top level selection, in which case the scheduler 

18 is free to select any appropriate sub-resource to accomplish the task. In some 

19 cases, the individual resource may need to be specified, in which case that 

20 particular resource will be used. The amount of work 212 includes both duration, in 

21 days in the preferred embodiment, and load, expressed as the capacity, in hours 

22 per day, that the resource requirement uses. 
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1 Ability is the requirement for a minimum competency or experience level for 

2 the resource. If a higher competency resource is used for the task, the duration 

3 may be shortened by an amount proportional to the skill differential. The change to 

4 duration based upon competency is completely application dependent, and must be 

5 defined in advance. 

6 Progress 216 preferably includes the actual date the task was started, the 

7 completion date if it has been completed, and the estimated remaining duration if 

8 the task has been started but not yet completed. This information is generally 

9 updated by project team members as tasks are performed. 

10 Scheduling requirements 218 can be considered generally as policies 220 

11 and constraints 222. Policies 220 indicate how constraints should be enforced. 

12 This includes flags indicating whether additional duration can be used, and whether 

13 certain constraints are to be enforced. Constraints 222 points to the constraints to 

14 be used in scheduling this task. 

15 Constraints are of several types. Some constraints are built into the 

16 scheduler, such as the constraint that a resource cannot be used simultaneously by 

17 two resources, and that precedence relations will be enforced. Also, tasks that 

18 require material resources are not scheduled until the materials are available. 

19 Others are controlled by the users, and can be changed as part of the modeling 

20 process to study alternative scenarios. These include fixed start and completion 

21 dates, allowable delays between sequential tasks, whether or not overtime is 
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1 allowed to complete a task, and penalties for differences in location for resources 

2 used in the same task or project. 

3 Once all of the described information is completely specified, the system 

4 preferably uses genetic algorithms to determine optimum schedules that meet all of 

5 the constraints. By changing task and resource constraints, and specifying certain 

6 resources and task dates, a schedule is generated that meets all of the goals 

7 originally set in the portfolio plan, and is attainable by the resources available. 

8 Because of the fast computational nature of genetic algorithm programs, numerous 

9 what-if scenarios can be computed in a reasonable time. 

10 While the invention has been particularly shown and described with 

11 reference to a preferred embodiment, it will be understood by those skilled in the art 

12 that various changes in form and detail may be made therein without departing from 

13 the spirit and scope of the invention. 

14 
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1 What is claimed is: 



11. A method for scheduling development planning for a plurality of products, 

2 comprising the steps of: 

3 receiving as input a list of a plurality of products to be developed, and a list 

4 of required completions dates for the development of each product; 

5 receiving as input one project definition for each product, the project 

6 definitions each defining a plurality of tasks required to complete the project, and 

7 resources required to complete each task, at least one of the tasks for at least 

8 one project requiring a material to be provided by an outside party; 



9 receiving as input a list of available resources, each resource having a 

10 capacity as a function of time; 

11 receiving as input a list of materials available from outside parties, and a 

12 schedule of availability of such materials; and 

13 generating a schedule including all tasks for all projects, such schedule 

14 allocating all resources such that each resource is allocated at a level less than 

15 or equal to its capacity, such schedule also scheduling tasks that require 

16 materials from outside parties at a time when such materials will be available. 
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1 2. The method of Claiml, wherein each available resource is assigned an 

2 ability level, and wherein each task requiring a resource specifies a minimum 

3 ability level to be used for that task, and wherein the generated schedule 

4 allocates, to all tasks, resources that have an ability level at least as high as the 

5 specified minimum ability level. 

6 



Patent Application /0544MH-36339 



Page 25 of 25 



6 



1 3. A system for scheduling development planning for a plurality of products, 

2 comprising: 

3 a list of a plurality of products to be developed, and a list of required 

4 completions dates for the development of each product; 

5 a project definition for each product, the project definitions each defining a 

6 plurality of tasks required to complete the project, and resources required to 
U 7 complete each task, at least one of the tasks for at least one project requiring a 
'% 8 material to be provided by an outside party; 

0* 9 a list of available resources, each resource having a capacity as a function 

2 10 of time; 

:2 11 a list of materials available from outside parties, and a schedule of 

fr?' 

12 availability of such materials; and 

13 a scheduler for generating a schedule including all tasks for all projects, 

14 such schedule allocating all resources such that each resource is allocated at a 

15 level less than or equal to its capacity, such schedule also scheduling tasks that 

16 require materials from outside parties at a time when such materials will be 

17 available. 
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1 4. The system of Claim3, wherein each available resource is assigned an 

2 ability level, and wherein each task requiring a resource specifies a minimum 

3 ability level to be used for that task, and wherein the generated schedule 

4 allocates, to all tasks, resources that have an ability level at least as high as the 

5 specified minimum ability level. 
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ABSTRACT 



1 A product development scheduler uses a distributed, constraint based 

2 system for modeling allocation of resources. All resources for all active 

3 development projects are provided at a central location, so that resources are not 

4 allocated twice across different projects. Real time availability of resources allows 

5 accurate modeling, and changes in resource status are reflected by the scheduler. 

6 Availability of materials are tracked through the supply chain to ensure true 

7 availability for planning purposes. 
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